Hardware Queues may consist of a memory, producer input port, producer index pointer, consumer output port, consumer index pointer, and logic to detect full and empty conditions by comparing a consumer pointer to a producer pointer. These hardware queues may access semantics as either last in first out (LIFO) or first in first out (FIFO). Hardware Queues may be used in a variety of ways including elasticity, connecting hardware to hardware, hardware to firmware, firmware to firmware, firmware to software driver and the like. Failures and errors that may occur in Hardware Queue design are often difficult to investigate and cure since accurate evidence of failure may be difficult to locate and track. Errors may include missing items, multiple copies of singular items, non-existent items (output items that were not input) and the like. Causes of these failures and errors are varied, and may include timing issues and issues with the hardware or software attached to the consumer or producer port. Further failures may be caused by FIFO logic problems such as faulty full or empty detect logic, erroneous double index pointer incrementing, or failing to increment the index pointer. The hardware queue in question might be a part of a large chain of queues with intervening hardware and software causing difficult failure location. When analyzing performance of many interrelated hardware queues, it may be difficult to determine which hardware queue is the weak link in a design.
Previous attempts at Hardware Queue failure analysis include a logic analyzer trace of internal signals into or out of the hardware queue. These analysis methods can either be n-board logic analyzer or external (by making the signals available externally through test mux interfaces). The primary disadvantage of this method is that a limited number of hardware queues can examined at the same time, making the debug process long and tedious, because the failing scenario will have to be created over and over again. Also the failing scenario might take a long time to reproduce.
Therefore, it would be advantageous if a method existed providing for a hardware queue whose state may be paused at any time. Such method may monitor a plurality of hardware queues, receive an input to pause the hardware queues, store various inputs from the hardware queues to a memory, analyze the stored values to diagnose an error, and restore the hardware queues to a previous state to recreate an operational scenario.